欢迎来到我们案例研究的第二部分, 我们把三张训练dvd转换成多个H.264文件用于自适应流式传输(如果你错过了第一部分,请点击这里). 在本节中, 我将详细说明我们如何在自适应流媒体产品中提供文件的数量及其配置, 以及我们如何测试多文件服务. 提醒一下, 完成项目取决于满足客户的质量相关目标, 我将在这部分的最后讨论.
我写过很多关于自适应流的文章,最全面的是 自适应流在现场 为 流媒体杂志. 在那篇文章中, 我问了一些制片人,比如特纳广播公司, NBC(通过微软), 哈佛大学, 以及德国之声有关流计数的具体问题, 数据速率, 决议, 以及编码方法. 如果你不熟悉自适应流媒体, 我会阅读那篇文章,以便更好地了解与压缩相关的决策, 回来看看他们是如何应用于这个项目的.
具体地说, 因为观众都是专业的工程师, 客户觉得连接带宽会非常高. 除了, 因为视频很长,而且是为了训练, 客户认为质量必须是好的, 因此,降低到超低的数据速率既没有必要也不建议.
最后, 因为视频是4:3的SD源, 最大分辨率为640x480, 所以我们可以只制作三到四个流媒体,仍然覆盖最相关的观众. 最初,我们决定尝试四种速度为400kbps, 700kbps, 1的流.0 Mbps和1.5 Mbps,但在我们第一次向客户演示后,最终下降了最低质量的流. 下面是更多的经验.
在某种程度上, 我们在这里的决定是由位于视频最开始的一些介绍性镜头驱动的,您可以在图2中看到. 基本上, 当以480x360分辨率编码,然后放大到640x480(如图所示)时,它看起来很糟糕。, 但是当编码为640x480时,数据速率是相同的(右图). 由于客户的目标是像网。flix一样的体验,我们不想在介绍时搞砸它, 所以我们采用了原生分辨率. 有趣的是, 这段视频还说明了我们在哪里对DVD片段进行了去隔行处理以及使用了哪种算法.
请注意,如果我们的目标是低得多的数据速率,或者如果内容不包含具有这种精细细节的部分,那么这个决定可能会有所不同. 我们最初的计划是在640x480和480x360下测试400kbps的流, 两者都显示为640x480, 并选择最高质量的选项. 如果你想在这两种方法中做出选择, 您应该运行一些并行测试,看看哪种测试最适合您的内容.
第二个, 当为自适应流生成多个文件时, 你需要一个一致的关键帧间隔,在场景变化时没有关键帧. 由于Adobe的动态流只能在关键帧切换流, 关键帧间隔应该比平时短. 通常我建议关键帧间隔为10秒, 在这些视频中,我用了三秒钟.
请注意,当生产其他技术, 比如苹果的HTTP直播, 微软的流畅流媒体, 以及Adobe基于rtmp的自适应流媒体, 其他的考虑, 比如块大小, 也重要. 我在前面提到的文章中提到了一些,但在我的书中提供了更多的信息, 视频压缩Adobe Flash,苹果设备和HTML5.
你必须为自适应流专门编码的另一个领域与音频参数有关, 对于所有流,哪个应该是相同的. 否则,您可能会在场景变化时听到爆裂声或其他伪影. 由于视频中的大多数音频都是单声道语音,所以我在所有文件中都以64kbps的单声道编码.
幸运的是, Stefan在Adobe的开源媒体框架(OSMF)中找到了一个播放器,它提供了强制流切换的控件, 他可以修改它来播放我们的文件. 如图4所示,使用了Adobe提供的视频. 如果你看一下玩家控制栏, 你会看到字母Q, 你点击它可以显示Q-和Q+控件,点击它可以在比特流之间切换. 如你所见, 播放器显示文件的比特率,然后在控制之间播放(即408 kbps).
我们大多数人都看过以一种或另一种自适应流媒体形式分发的视频, 但是很难判断流何时被切换, 如果没有复杂的网络设备,很难强迫流切换. 虽然OSMF播放器是公认的粗糙, 流切换本身是绝对完美的, 没有停歇, 跳过, 或者音频伪影. 我印象深刻, 客户端也是如此——通过流切换, 但不是一些流的质量. 正如我在第一期中提到的, 如果我们不能达到或接近Netflix的质量,客户就不想继续前进. 我制作的一些流没有达到这个标准.
这是为什么. 我们编码的大多数视频都是穿插着幻灯片的简单的说话头像, 一些数字, 还有观众的b-roll——很容易压缩内容. 另一方面, 视频的介绍制作得相当高, 用一些非常艺术的平底锅, 缩放, 转换, 以及难以压缩的素材,如图2所示.
我最初的测试视频从中间截取了一部分, 视频在所有数据速率下看起来都很好. 但后来我意识到,这并不能代表整体质量, 所以我重新编码了一个片段,其中包含了一些难以编码的介绍镜头, 和易于编码的说话头, 这就是我们在OMSF播放器中向客户展示的内容. 整体, 质量很好, 除了在剪辑开始时快速缩小, 在所有数据速率下看起来都很糟糕(图5), 以及下面讨论的一些非常详细的镜头. 就在视频开始的时候,它就像一个疼痛的拇指一样突出,给人留下了不好的印象.
比尔, 客户端, 是坚决的, 事实说明, “即使是1500美元,样本也不太接近Netflix的体验. 如果这是我们能从Flash中得到的最好的东西,那么你就不应该再继续下去了. 我可能需要重新考虑这个项目,并找到一个Silverlight主机来取代AWS."
来解释一下最后的评论, 因为Netflix使用Silverlight, 比尔认为问题出在技术上, 不是编码技术或素材. 这时,我打电话给比尔,我们讨论了三点.
首先,无论他是使用Silverlight还是Flash, H.264可能是编解码器,改变平台根本不会影响质量. 第二个, 项目开始时的素材根本不可能以高质量压缩, 不考虑平台和技术. 第三, 原始编码或多或少是草稿编码,以测试自适应流的操作, 我觉得我可以做得更好.
我们同意从测试剪辑中删除第一个快速缩放, 在他再次查看之前,我会将结果测试剪辑重新编码为建议的最终参数. 这也是我们决定放弃400kbps的片段,并使用剩下的三个700kbps和1.0和1.5 Mbps.
总的来说,Stefan完成了他的工作——自适应流媒体看起来很棒. 但如果我不能提高质量,这个项目就会付之东流. 下周请收看我的演讲.
Jan Ozer的文章首先出现在在线视频上.网。